Companies today are tasked with implementing solutions for many types of integration challenges within their respective enterprises. Many of these challenges involve issues of application integration (e.g., integration among and/or between software applications and/or other systems) and fall into common patterns.
For example, a first area relates to propagation of similar business objects from one system to multiple other systems, such as, for example, in an order status change or a product price change. A second area relates to synchronization of similar business objects between two or more systems to obtain a single view, such as, for example, a real-time synchronization of customer, product registration, product order, and product SKU information among several applications. This is the most common issue requiring an integration solution. In a one-way synchronization, there generally is one system (e.g., resource) that acts as a data source and one or more resources that are targets of the synchronization. In a two-way synchronization, every resource often is both a potential source and target of a synchronization. There generally is not a single resource that acts as the primary data resource. Thus, a change to any resource should be reflected in all other resources. A third area involves information joined from multiple sources into a common destination system, such as, for example, communicating pharmacy customer records and prescription transactions and website data into a central application and database.
Various tools have been provided that enable a user to design and deploy solutions that address these challenges using, for example, the publish-and-subscribe model or one of its variants. The publish-and-subscribe model is a specific type of message-based solution in which messages are exchanged anonymously through a message broker. Applications that produce information that needs to be shared make this information available in specific types of recognizable documents that they publish to the message broker. Applications that require information subscribe to the document types they need.
At run time, the message broker receives documents from publishers and then distributes the documents to subscribers. The subscribing application processes or performs work using the document and may or may not send a response to the publishing application.
In a typical system, an integration server or applications running on an integration server publish documents to a broker. The broker then routes the documents to subscribers located on other integration servers. The integration server and the broker share a fast, efficient process for exchanging documents across the entire system.
Although such techniques have been successful in providing solutions to the above-described challenge areas, further enhancements are still possible. For example, the integration server (IS) “Trigger Subsystem” provides a rich infrastructure for message processing (e.g., asynchronous message processing). However, this functionality is only available for messaging over a proprietary (e.g., broker) messaging protocol. Thus, users currently have to make a difficult design decision, choosing between either a feature-rich proprietary protocol, or a standards-based interoperable messaging protocol (e.g., JMS).
One approach to solving this problem has involved the use of a JMS adapter provided to an integration server. Thus, both a proprietary “trigger subsystem” (provided by the integration server for proprietary messaging) and a separate JMS adapter were provided to the integration server.
Unfortunately, this approach is somewhat incomplete. In particular, despite the availability of a JMS adapter for standards-based interoperable messaging, the “trigger subsystem” capabilities could not be fully used in connection with JMS. That is, users who want the extended capabilities of the “trigger subsystem” while using the JMS adapter would have to custom-implement those capabilities in their applications for every new application. This often imposes significant configuration and programming requirements and has led to a plethora of non-standardized implementations of the same and/or similar functionality. This problem is further exacerbated, as JMS is still in the process of being standardized for use in the in web-services context. In essence, this means that if capabilities comparable to those of the proprietary broker were required, they would have to be implemented in the application services layer time and time again. Even where such approaches have been implemented, they have not been standardized, e.g., because enterprises are different in terms of their organizations, processes, requirements, infrastructure, etc.
Thus, a problem remains in that there is not a single means to couple the current “trigger subsystem” and all of its capabilities with standards-based messaging (e.g., via JMS). Accordingly, there remains a tradeoff between a feature-rich proprietary protocol on the one hand, and a standards-based interoperable messaging protocol (e.g., JMS) on the other.
Thus, it will be appreciated that there is a need in the art for improved techniques for providing application integration solutions in one or more of the above-noted and/or other areas.
One aspect of certain example embodiments of this invention relates to a messaging layer that provides a rich feature set for addressing application integration challenges that is accessible through both proprietary and open messaging constructs existing outside of the application layer. In certain example embodiments, such messaging constructs may be in the form of “triggers,” and such triggers may enable a publish-and-subscribe type solution to such application integration challenges in certain example embodiments. The triggers of certain example embodiments may be JMS triggers.
Another aspect of certain example embodiments relates to parallel subsystems being accessible through a common trigger subsystem provided as value-added layer above the respective trigger subsystems.
Still another aspect of certain example embodiments relates to substantially fully embedding JMS as a peer to the proprietary messaging protocol in the integration server trigger subsystem so that all or substantially all existing capabilities would be JMS-enabled.
A further aspect of certain example embodiments relates to the use of a messaging layer that enables JMS messaging without the use of a special adapter provided to an integration server. Furthermore, in certain example embodiments, such a messaging layer may make it possible to avoid making any changes to the JMS trigger itself and/or may reduce the need for custom programming and/or implementation at the application service level in certain example cases.
In certain example embodiments, a trigger subsystem for use with an application integration system is provided. At least one proprietary trigger subsystem is embedded in the trigger subsystem. At least one standards-based trigger subsystem is substantially fully embedded in the trigger subsystem. Common trigger facilities are provided for the at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem. The at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem are provided as parallel subsystems. Each said proprietary trigger subsystem and each said standards-based trigger subsystem is configured to access a corresponding trigger layer. Each said trigger layer is configured to provide triggers in a format associated with the respective trigger layer. The triggers include instructions for causing a process to be executed in or by the application integration system or a component thereof.
In certain other example embodiments, there is provided a messaging layer for use across an integration server or an integration server instance provided as a component in an application integration system. A trigger subsystem includes at least one proprietary trigger subsystem embedded therein, at least one standards-based trigger subsystem substantially fully embedded therein, and common trigger facilities for the at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem. The at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem are provided as parallel subsystems in the trigger subsystem. A plurality of parallel trigger layers is respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem. A plurality of messaging API layers is respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem. Each said trigger layer is configured to provide triggers in a format associated with the respective trigger layer. The triggers include instructions for causing a process to be executed in or by the application integration system or a component thereof.
According to certain example embodiments, a method of configuring an application integration system is provided. There is provided a messaging layer for use across an integration server or an integration server instance provided as a component in the application integration system. In the messaging layer, a trigger subsystem is included. At least one proprietary trigger subsystem is embedded in the trigger subsystem. At least one standards-based trigger subsystem is substantially fully embedded in the trigger subsystem. The trigger subsystem is configured to provide common trigger facilities for the at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem. A plurality of trigger layers is respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem. A plurality of messaging API layers is respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem. The at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem are provided as parallel subsystems in the trigger subsystem. Each said trigger layer is configured to provide triggers in a format associated with the respective trigger layer. The triggers include instructions for causing a process to be executed in or by the application integration system or a component thereof.
According to certain other example embodiments, there is provided a method of operating an application integration system based on a publish-and-subscribe model or a variant of the publish-and-subscribe model. There is provided a messaging layer for use across an integration server or an integration server instance provided as a component in the application integration system. The messaging layer includes a trigger subsystem included therein, with the trigger subsystem comprising at least one proprietary trigger subsystem embedded therein and at least one standards-based trigger subsystem substantially fully embedded therein, and with the trigger subsystem being configured to provide common trigger facilities for the at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem. Also included in the messaging layer is a plurality of trigger layers respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem, with each said trigger layer being configured to provide triggers in a format associated with the respective trigger layer. In the triggers, instructions are included for establishing subscriptions to publishable document types and for specifying one or more services to process documents received by the subscriptions. One or more documents are published to one or more subscribers in dependence on the instructions included in the corresponding trigger(s). Each said document is processed in dependence on the instructions included in the corresponding trigger(s). The at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem are provided as parallel subsystems in the trigger subsystem.
Although these features, aspects, and example embodiments are advantageous, further improvements are still possible. For example, it would be desirable to use the standards-based triggers to process messages of the same or different types over the triggers' transport layer. That is, it would be advantageous to use a first standards-based messaging protocol (e.g., the JMS messaging protocol) to create a trigger so that a message envelope according to a second standards-based messaging protocol (e.g., SOAP) may be communicated over the first standards-based messaging transport layer. This approach enables a user to potentially realize the benefits of associated with both the standards-based trigger as well as the standards-based messages. It would be further desirable to implement a standards-based and configuration-driven approach to such techniques. For example, a standards-based and configuration-driven approach to such techniques could be implemented in accordance with a binding specification that links or binds the standards-based triggers to the second standards-based messaging protocol.
Thus, it will be appreciated that there is a need to move away from proprietary implementations and towards standards-based and configuration-driven approaches to messaging that involve using standards-based triggers to enable other message type envelopes to be sent over triggers' transport layers.
One advantageous protocol for the messages is SOAP. As is known, SOAP is a lightweight protocol for the exchange of information in a decentralized, distributed environment. SOAP is an XML-based protocol that includes three parts: an envelope that defines a framework for describing what is in a message and how it is to be processed, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses. SOAP messages may be used, for example, to exchange structured information in the implementation of web services in computer networks.
Unfortunately, current products do not offer a standards-based and configuration-driven approach for processing SOAP messages over the JMS transport. Indeed, if any SOAP over JMS messaging approaches were provided, they necessarily would have to rely on proprietary technology rather than a standards-based and configuration-driven approach. This is due, in part, to the fact that a working draft for the SOAP over JMS 1.0 specification has only just recently been released by the W3C and that web service solution providers other than the assignee of the instant invention generally are not deeply invested in providing standards-based and configuration- driven approaches to messaging. A copy of the recently released “last call” W3C specification can be found online. The absence of such a binding specification between SOAP and JMS has made it impossible to implement a standards-based and configuration-driven approach to providing such features. Thus, even if web services solution providers were interested in standards-based and configuration-driven protocols, they could not do so reliably and predictably.
Accordingly, it is believed that the state of the art relies on proprietary bindings, which disadvantageously lock users in to closed systems that may not necessarily be changeable and extensible, and which even might run afoul of any standards ultimately promulgated by a standards-setting organization such as the W3C.
Accordingly, one aspect of certain example embodiments relates to providing a standards-based and configuration-driven approach to messaging where a first standards-based messaging protocol is used to create a trigger so that a message envelope according to a second standards-based messaging protocol may be communicated over the first standards-based messaging transport layer. In other words, in certain example embodiments, a trigger according to a first protocol may have a message according to a second protocol associated therewith so as to enable the message to be communicated over the first protocol's transport layer.
Another aspect of certain example embodiments relates to providing support for processing SOAP messages over the JMS transport.
Certain example embodiments relate to an application integration system configured to exchange messages via a message broker. A runtime trigger is configured to receive messages from a message producer via a client queue of the message broker in accordance with a context retrieved from a context pool. The message is received over a transport protocol and a message envelope is associated therewith. The message envelope is formatted in accordance with a second messaging protocol. The runtime trigger is further configured to extract the message envelope from the runtime transported message. A web service stack is configured to receive the message envelope extracted from the transported message by the runtime trigger and is further configured to invoke an appropriate service from a plurality of possible services in accordance with instructions included with the message envelope.
Certain example embodiments relate to an application integration system configured to exchange messages via a message broker. A web service connector is configured to invoke a remote web service by generating a runtime message envelope to be delivered to the web service stack for transport to a client queue of the message broker. The message is sent over a transport protocol and has a message envelope associated therewith. The message envelope is formatted in accordance with a second messaging protocol. The web service connector is generated from a web service descriptor (WSD). The WSD specifies at least a format of the message envelope, as well as a destination (e.g., a JMS destination). Optionally, one or more network locations at which the web service can be invoked. The message broker is configured to place any received messages into the client queue for the message consumer.
Certain example embodiments relate to an application integration system configured to exchange messages via a message broker. A web service connector is configured to invoke a remote web service by generating a runtime message envelope to be delivered to the web service stack for transport to a client queue of the message broker. The message is sent over a transport protocol and has a message envelope associated therewith. The message envelope is formatted in accordance with a second messaging protocol. The message consumer (or runtime trigger) is configured to receive the runtime message from the producer in accordance with a context retrieved from a context pool. The message consumer is further configured to extract the message envelope from the transported runtime message. A web service stack is configured to receive the message envelope extracted from the transported runtime message by the message consumer and is further configured to invoke an appropriate service from a plurality of possible services in accordance with instructions included with the message envelope. The web service connector is generated from a web service descriptor (WSD) at design time. The WSD specifies at least a format of the runtime message envelope, as well as one or more network locations at which the web service can be invoked. The message broker is configured to place any received runtime messages into the client queue for the message consumer.
Certain example embodiments relate to a messaging method in an application integration system. A message broker configured to deliver messages from a message producer to a message consumer is provided. A web service connector is enabled, with the web service connector being configured to invoke a remote web service in communication with the message consumer by generating a runtime message envelope to be delivered to the web service stack for transport to a client queue of the message broker. The runtime message is sent to the message broker via a dispatcher connected to the web service connector using a connection retrieved from a connection pool, with the runtime message being sent over a transport protocol and having a message envelope associated therewith, and with the message envelope being formatted in accordance with a second messaging protocol. The runtime message from the producer is received at the message consumer via the broker in accordance with a context retrieved from a context pool. The message envelope is extracted from the transported runtime message. The message envelope is passed from the message consumer to a web service stack. An appropriate service is invoked via the web service stack from a plurality of possible services operably connected to the web service stack in accordance with instructions included with the message envelope. The message broker is configured to place any received runtime messages into the client queue for the message consumer.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.